{\rtf1\ansi\ansicpg1252\cocoartf949\cocoasubrtf350
{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
{\colortbl;\red255\green255\blue255;}
\paperw11900\paperh16840\margl1440\margr1440\vieww9000\viewh8400\viewkind0
\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\ql\qnatural\pardirnatural

\f0\fs24 \cf0 For our previous release, we settled on a rough but clear design that emphasised the separation of different aspects of the system, and started our implementation. The design broke up graphics system dependent code, and code that performed the physics based calculations. \
\
\
\
\
Our design has since matured, and there has been a level of early refactoring. For example we previously used basic inheritance as a method of giving a virtual body physical characteristics, after some consideration (partly following several lectures emphasising the problems of inheritance) we decided that this was not a true inheritance relationship and that using composition (every body "has" physics) was a much more natural and less restricting relationship.\
Following on from this, we decided that every body required a shape, as this provided a simple way of extending our library in the future, and meant we didnt have to worry about making generic shape code now (as we could focus on say, circles and worry about squares later). We also decided that a Java 3D body was a type of body (and so is any graphics system dependant body)\
And that a Java 3D world should implement a world interface that specifies how a general world should look (can add and remove bodies, returns an object capable of displaying it) this allowed the object controller class to have a world field, meaning that should it wish, an application needs only 1 reference object into the library. Please see the UML diagram for a more visual representation of the objects in our library.\
\
Analysis for this release has focused primarily upon the physics aspects and algorithms.\
Also analysis of the interaction between objects has led to some of the design changes describe above (e.g. making World an interface) which have been done to try and separate out different aspects of the system, hopefully creating a more generic library, one that is easily adaptable to different graphical systems. \
\
In terms of implementation experiences, our first major extreme programming moment came when we realised that to design such a system well at the beginning would take far too long, as we didnt understand many of the issues, for example how we would calculate collisions. It quickly became aparent that we needed a basic design quick, and that as long as it was quite loose, we could change our minds later. This has happened already, for example creating world as an interface was a spur-of-the-moment idea that makes the library more generic and less tightly bound. While our design is very broadly based around the same breaking up of the problem, it has changed much with respect to its details, such as how objects interact.\
The idea of collective ownership has reinforced the version managing etiquette of frequent commits and updates, as we have found. It is extremely easy to not do this, but that can lead to problems which are solved by simply regularly updating & committing. \
\
The tools we are using are svn for source control, the sun java compilers and Xcode, although this is being used as a text editor only (albeit one that supports syntax highlighting and indentation). We are also using the Java 3D libraries to support the demonstration of the more general aspects of our project, although we are not utilising its 3D functions. Our reason for this, is that we wish to concentrate on the physics elements, and so 2D is adequate but J3D provides a simple way of creating and drawing a scene graph, without having to re-implement such aspects as part of our engine.\
We intend to use other standard java tools, such as javadoc and unit.}